![]() |
![]() |
![]() |
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
![]() |
![]() |
To access the contents, click the chapter and section titles.
Oracle Performance Tuning and Optimization
Network Enhancements Network performance can be quite a bottleneck for this type of system. Because large amounts of data are transferred across the wire, a high-speed link is imperative. You may be able to take advantage of the new 100Base-T technology or benefit from a fiber-optics link. The faster the network link, the faster the data is transferred. You may find it beneficial to subnet your networks between the high-access systems. Try to use the latest technology (such as 100 megabit Ethernet) to provide for future expansion.
Performance VerificationTo verify that changes you have made have positively affected performance, you must develop some sort of test plan. The test plan should consist of an application that is very similar to the application that will be used to access this data. The closer your tests are to the actual application, the more accurate the performance verification will be. A good documented test plan allows you not only to verify system performance but to try new tuning parameters or new features you may want to implement in the future. The following sections look at what should be tested in the RDBMS and the operating system. What To Test in the RDBMSThe test should be designed to access the data in a manner consistent with the data access patterns seen with the actual application. If the application involves video streams across the network, verify this data flow in a manner as similar to production as possible. If strict data throughput criteria are involved, verify that you can meet this criteria by using a database that is close in size to the production database. Once you build an effective load test with repeatable results, start changing some of the parameters described in Part II of this book and earlier in this chapter. By changing only one parameter at a time, you can easily see which changes affect performance. Before changing anything, set your expectations for the changes you are going to make. If the results dont turn out as expected, try to understand why they didnt. Be sure to log the results so that you have a reference of what changes were effective and what changes were not. What To Test in the OSFor the most part, the OS is tested with the RDBMS. If you have to change some specific OS parameter to increase a limitation, you usually dont have to retest the performance. Any limit change is usually associated with an RDBMS change, and the two can be tested together. Other OS changes such as feature enhancements should be tested with the RDBMS, but you should more closely watch and analyze these results. You should carefully analyze things such as scheduler changes and cache affinity that may have an adverse affect on the system to verify that performance has not degraded. As stated earlier in this book, the OS is primarily a vehicle for the RDBMS to use. The primary goal in tuning the server OS is to reduce overhead and optimize the I/O, memory, and networking subsystems. BenchmarksStandardized benchmarks are a good way to judge how well a system is performing and to compare different hardware platforms. If they are available to you, standardized benchmarks are also a good way to analyze the performance of your particular platform. Although you can benchmark an OLTP system with the TPC-C benchmark and a decision support system with the TPC-D benchmark, there are no standardized benchmarks currently used to demonstrate the performance of BLOB access. The best way for you to benchmark your system is with the production application. If possible, modify this application to time certain events, such as the following:
In this manner, you can quantitatively measure the performance of your system. If you make any changes, you can run them against this data and compare the results. Try to create a benchmark that has a variable load so that you can push the system to its limits to gather maximum load information. SummaryThis chapter looked at a system designed to access BLOB data. Specifically, it looked at the methods and data patterns generated when BLOB data is accessed. By looking at these data access patterns, you discovered some ways to design a system to take advantage of this information. By taking advantage of large block sizes and multiblock reads, you can increase the performance of access to this data. The I/O subsystem is of critical importance in this type of system and should be sufficient to handle the required workload. This type of system is frequently used to view the same data over and over again. This is advantageous because it allows you to try new tuning parameters and be innovative. By having essentially the same job to run, you can quantitatively measure the results of any changes and determine whether performance has changedeither positively or negatively. By logging the results of these tests, you gather valuable data that can help determine which changes should be tried in the future.
|
![]() |
Products | Contact Us | About Us | Privacy | Ad Info | Home
Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. |